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(54) A secure and open computer platform 

(57) A computer platform is described that provides 
control features to allow for the protection of intellectual 
property rights and prevent malfunctioning of the plat- 
form. The platform uses 1) a secure operating system 
including a secure memory management system, 2) 
public key encryption, 3) data authentication through 
digital signatures and 4) application/data approval 
through a flexible access policy through the use of object 
handlers and an application program approval process. 
Through these four control features, the platform pro- 
vides the ability to control access to data and minimize 
the effects of computer malfunctions. 
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Description 

[0001 ] This invention relates to an apparatus and sys- 
tem for providing a computer platform, in particular, one 
that controls the operation of the application programs 5 
and object files to adequately protect against computer 
malfunctions. 

[0002] In creating a computer platform, one concern 
is the amount of control that the platform retains over 
how application programs operate and data files are ac- 10 
cessed on the platform. A computer platform can have 
control features that implement rules and restrictions on 
how application programs run and data files are ac- 
cessed on that platform. Each application program op- 
erating on this platform would then usually be written in is 
accordance with these rules or restrictions. 
[0003] Control features of a platform are intended to 
effect some type of security to the platform user and/or 
the application program or object file writer. For exam- 
ple, a computer platform can contain certain control fea- 20 
tures to prevent undesirable computer malfunctions 
such as ones caused by a computer virus or a badly 
written application program. In other instances, a com- 
puter platform can also have control features to prevent 
violations of a person's intellectual property rights that 25 
can occur by unauthorized duplication of copyrighted 
material. 

[0004] The more control features that are implement- 
ed in a given platform, the less flexible the platform is in 
accommodating application programs. If an application 30 
program is written to comply with a particular platform's 
rules, that application program might only be capable of 
being used on that platform. Conversely, application 
programs written to comply with a different platform's 
rules might not operate on this platform. 35 
[0005] An application programmer will usually have to 
determine which platform the program application is be- 
ing written for before writing the application program. 
Consequently, an application programmer will usually 
favorthe platforms that are the least restrictive because 40 
it increases the chance of the application program being 
able to be run on the most platforms. Thus, it is more 
advantageous for a platform to use the least amount of 
rules in implementing the desired control features. 
[0006] If a computer platform is intended to handle 43 
sensitive copyrighted material, then prevention of unau- 
thorized copying becomes paramount and other control 
issues are less important. With the advent and popular- 
ity of digital publications and electronic distribution of 
publications to be read on electronic readers, protection so 
of copyrights on a computer platform has become im- 
portant. 

[0007] Consequently, it would be advantageous to 
provide a computer platform that provides control fea- 
tures to prevent unwanted violations of intellectual prop- 55 
erty rights and still allows enough flexibility for applica- 
tion programs and object files. It would also be advan- 
tageous to provide a computer platform that provides 



control features that protect against malfunctions of pro- 
gram applications on the platform. 
[0008] The current invention involves a system that 
provides enough control features to create a secure 
platform and yet maintain the flexibility to be able to op- 
erate and run a large variety of applications. 
[0009] The present invention is defined in the accom- 
panying independent claims. Some preferred features 
are recited in the dependent claims. 
[0010] In a preferred embodiment the invented sys- 
tem entails utilizing control features which in combina- 
tion protect against malfunctions in a computer platform 
and provides the ability to prevent unauthorized access 
to copyrighted material. These security measures in- 
clude: 

1) A secure operating system, including a secure 
memory management system; 

2) Public key encryption; 

3) Data authentication through digital signatures; 
and 

4) Application program/object file approval. 

[0011] Providing a secure operating system can entail 
two aspects: 1) ensuring that the operating system is 
approved for the platform and 2) creating firewalls 
around application programs and object files that oper- 
ate on the platform. The term "firewall" is used herein to 
refer to the arrangement in the computer platform that 
employs certain memory management -components of 
the operating system to bar access to an application pro- 
gram or an object file in memory. Access to the object 
file or application program can be granted only if the re- 
quired permission is obtained, 
[0012] Encryption generally entails reformatting data 
using an "encryption" key such that no one else will be 
able to utilize or read that data if they do not have an 
appropriate "decryption" key. 

[0013] Data authentication entails the ability of verify- 
ing the author and title of data to ensure that the data is 
properly authored and has not been tampered with from 
the time of creation by that author to the receipt by the 
platform. 

[0014] Application/data approval allows application 
programs to reject the type of object files that it will op- 
erate on and also allows the object files to reject the ap- 
plication through a flexible access policy through the use 
of object handlers and an application program approval 
process. 

[0015] In the embodiment of the invented system, 
these four types of control features are available to be 
accessed by an application program or data file while 
on the platform. Application programs and files -can op- 
erate on the platform without utilizing the control fea- 
tures. Through these four types of control features, a 
computer platform that is both open to accept various 
application programs and to protect intellectual property 
is provided. 
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[0016] The present invention can be put into practice 
in various ways, some of which will now be described 
with reference to the accompanying drawings, in which: 

Fig. 1 depicts the layout of an apparatus that imple- 
ments one embodiment of the present invention; 
Fig.2 depicts a flow chart demonstrating the crea- 
tion of a digital signature in accordance with one 
embodiment of the present invention; 
Fig. 3 depicts a flow chart demonstrating the signa- 
ture authentication process in accordance with one 
embodiment of the present invention; 
Fig. 4 depicts a flow chart demonstrating the crea- 
tion of a digital signature along with the further step 
of encryption in accordance with one embodiment 
of the present invention; 

Fig. 5 depicts a flow chart demonstrating the signa- 
ture authentication process along with the further 
step of decryption in accordance with one embodi- 
ment of the present invention; 
Fig. 6 depicts a flow chart demonstrating the crea- 
tion of a digital signature along with the further step 
of encryption in accordance with another embodi- 
ment of the present invention 
Fig. 7 depicts a flow chart demonstrating the signa- 
ture authorization process along with the further 
step of decryption in accordance with another em- 
bodiment of the present invention; and 
Fig. 8 depicts a flow chart demonstrating the steps 
of obtaining permission to access data in memory 
in accordance with one embodiment of the present 
invention. 

[001 7] Fig. 1 depicts the layout of a device that imple- 
ments one embodiment of the present invention. Com- 
puter platform 101 is provided with an input interface 
1 03 and an output interface 1 05 to allow the platform to 
obtain and transmit data. Input interface 1 03 and output 
interface 1 05 can be the same physical interface so long 
as it has the capability of both receiving and transmitting 
data. 

[0018] Hardware 107 is contained within computer 
platform 101 and implements firmware 109. Hardware 
1 07 also comprises memory registers 111 . The compu- 
ter platform's operating system will be loaded onto the 
hardware 107. 

[0019] The operating system ("O/S") is the foundation 
for the platform's security and digital rights management 
infrastructure. Firmware 109 contains an O/S verifier 
113 to authenticate the O/S before the O/S is loaded 
onto the hardware 1 07. Every time that the O/S is loaded 
or modified, the O/S verifier 113 must authenticate the 
O/S. O/S verification prevents potential circumvention 
of the security features that are implemented by the O/ 
S by unauthorized modification or substitution of the 0/ 
S. O/S verification does not impose any restrictions that 
would affect application programs running on the com- 
puter platform. 



[0020] O/S verification can be accomplished by vari- 
ous methods. One method of O/S verification that<:an 
be implemented uses digital signatures. Algorithms for 
creating and verifying signatures, and for generating the 

s public/private signing key pairs, and well known in the 
literature (c.f. Bruce, Schneier, "Applied Cryptography, 
second edition", John Wiley & Sons, Inc. New York 
(1 996). Figs. 2 and 3 depict digital signature verification 
for the O/S. This technique uses public/secret signature 

io keys. The first step 201 of the digital signature process 
is to create the data packet to be signed. The data pack- 
et is not necessarily just the O/S. Other information may 
be included as part of the data packet. For example, the 
credentials of the data can be included along with the 

'5 data packet. These credentials can include various 
items to identify the O/S, such as, the author, version 
and date of creation. 

[0021] After determining the data packet to be signed, 
the next step 203 is to apply a hash function to the data 
20 packet. A hash function essentially creates a value of 
fixed length called the hash value. The hash value is 
derived from characteristics of the data packet. Different 
data packets will usually create different hash values. 
Furthermore, it is computationally unfeasible to produce 
25 two different packets that have the same hash value. 
[0022] Each author is associated with one or more 
public/private pairs of signing keys. After the hash value 
is created (203), the hash value and the private signing 
key are input to a fixed, publicly known signing algo- 
30 rithm, that produces a digital signature as its output 
(205). €ach private signing key is unique to and known 
by a single author. The resulting signature is unique to 
the author who knows the private signing key. 
[0023] Fig. 3 depicts the steps that are taken to au- 
35 thenticate a signed data packet. The first step (301) is 
to recalculate the hash value of the data packet. This 
calculation reapplies the hash function to the data pack- 
et. The recalculated hash value, the signature and the 
public signing key are given as inputs to a fixed, publicly 
40 known signature verification algorithm (303). This algo- 
rithm outputs one of two values: "accept", meaning that 
the signature is to be accepted and "reject", meaning 
that the signature is to be rejected. 
[0024] The combination of creating a hash code and 
<s signing the hash code to create the digital signature al- 
lows the ability of ensuring that the signer created the 
signature and that the data packet has not been altered 
since the signature was created. 
[0025] For the O/S verifier, the authorized O/S pro- 
50 grammer's public signature key is burned into the hard- 
ware of the computer platform. This is necessary since 
the O/S is usually the first software that is loaded onto 
the computer platform and the computer platform must 
be able to verify that O/S when it is loaded. The author- 
55 jzed O/S programmer is usually the manufacturer of the 
computer platform. 

[0026] The procedures of creating a digital signature 
and authenticating the digital signature detailed in Figs. 
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2 and 3 are not limited to 0/S verification. These proce- 
dures can also be applicable to the process of authen- 
ticating application programs and object files. However, 
in addition to the procedures in Figs 2 and 3, authenti- 
cating application programs and object files can entail 
additional steps. 

[0027] Figs. 4 and 5 depict the procedures that can 
be implemented when authenticating signatures of ap- 
plication programs and object files. Similar to the proce- 
dures outlined in Fig. 2, the first three steps of creating 
a signature for application programs and object files are 
the steps of creating the data packet 401 , creating the 
hash value 403 and creating the digital signature 405. 
For application programs and object files, credentials 
should be included with the data packet and those cre- 
dentials should include at least the name of the author 
of the data. After the signature of the data packet is cre- 
ated, the data packet and the signature are both en- 
crypted with a public encryption key in step 407. 
[0028] Similar to the public/secret signature keys, the 
public encryption key is distinctively related to a private 
decryption key. However, both encryption/decryption 
keys are unique to a particular computer platform rather 
than a particular programmer. Another difference is that 
the public encryption key is used to encrypt the data 
while the private decryption key is used to decrypt the 
data. The private decryption key is kept secret and is 
only known to that particular computer platform. This 
permits only that computer platform access to the en- 
crypted data that has been encrypted with the public key 
unique to the platform. 

[0029] To authenticate the application program or ob- 
ject file, the first step 501 is to decrypt the encrypted 
data with the computer platform's private decryption key 
After the data has been decrypted, the decrypted data 
should consist of the data packet and the digital signa- 
ture. The next steps are to recreate the hash value of 
the data packet 503, and obtain the output from the pub- 
licly known signature verification algorithm 505. If the 
hash values do not match, then the data is erased from 
memory. 

[0030] Encryption of the data packet by using the pub- 
lic/private key technique provides rigorous protection 
against unauthorized access to the encrypted data by 
using two separate keys. This process, however, can 
utilize a substantial amount of the platform's processing 
resources. In addition, by encrypting the entire data 
packet, the encryption and decryption process can take 
a substantial amount of time to perform. 
[0031] Another alternative to using the public/private 
keys to encrypt the data packet is to utilize a less com- 
plicated encryption technique in addition to the public/ 
private key encryption. Figs. 6 and 7 depict the process 
of authenticating program applications and object files 
utilizing the second encryption technique. 
[O032] The first step 601 is to create the data packet. 
The second and third steps 603, 605 are to create the 
hash value and digital signatures of the data packet. The 



fourth step 607 is to encrypt the data packet and signa- 
ture with a single encryption/decryption key. This single 
key is used to both encrypt and decrypt. The single de- 
cryption key, itself, is then encrypted in the next step 609 
5 with the public encryption key that pertains to the par- 
ticular platform. 

[0033] To decrypt the data at the platform, the platform 
will first have to decrypt the single encryption/decryption 
key by using its private decryption key in step 701 . With 

10 the decrypted single encryption/decryption key, the plat- 
form now has the single encryption/decryption key and 
the data packet can then be decrypted. By separately 
encrypting the single encryption/decryption key with the 
public/private keys, the benefit of using the more secure 

is public/private encryption system to protect the entire da- 
ta packet is gained while maintaining a lower level of 
complexity. 

[0034] Once an application program or object file has 
been authenticated by the procedures detailed in Figs. 

20 4 or 6 or other similar procedures, it is considered to be 
secure data. If an application program or object file is 
not authenticated, it is considered to be insecure. 
[0035] By having the encryption/decryption keys 
unique to each computer platform, the invented system 

25 can restrict the availability of data to a particular com- 
puter platform. Any computer platform that does not 
have the correct private decryption key for an encrypted 
data packet cannot properly decrypt it. This ability, in 
combination with the signature authentication proce- 

30 dures, provides the ability to exert complete control over 
data transmissions to the computer platform by: 1 ) en- 
suring that any data transmission to the computer plat- 
form can only be read by that platform, and 2) ensuring 
that the data transmission has not been tampered with 

35 since the author of the data signed it. 

[0036] The computer platform's private decryption 
key must be burned into the hardware so that the plat- 
form will always be able to decrypt encrypted data pack- 
ets. In addition, authentication of application programs 

40 and object file should be done every time that an appli- 
cation program or object files is placed into the computer 
platform's memory. By performing this authentication 
every instance that data is loaded onto the platform, the 
system ensures that ail data loaded on the computer 

45 platform will be properly characterized as either secure 
or insecure. 

[0037] Although only the manufacturer's public signa- 
ture is burned into the hardware, the ability to designate 
application programs and object files as being secure is 

so not restricted to the manufacturer of the computer plat- 
form. Any programmer that writes an application pro- 
gram or object file to be used on the computer platform 
can designate it as being secure data. To accommodate 
different programmers in designating data as secure, 

55 the programmers can send all data to be designated as 
secure to the manufacturer. After authenticating the da- 
ta from the programmer, the manufacturer will then dig- 
itally sign the data with its secret signature key that cor- 
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responds to the public signature key that has been 
burned into the computer platform's hardware. 
[0038] Another embodiment entails sending the appli- 
cation programmer's public signature key to the manu- 
facturer. The manufacturer can then digitally sign this 
public signature key. This signature can then be ap- 
pended to signatures using the application program- 
mer's signature key. Since it has been signed by the 
manufacturer, the computer platform will accept the pro- 
grammer's public signature key as an additional signa- 
ture key that can be used to authenticate application 
programs and object files as being secure. These addi- 
tional public signature keys and the corresponding iden- 
tities are stored in a list by the O/S. This list will be ac- 
cessed by the O/S and the identity contained in the cre- 
dentials will be used to determine the appropriate public 
signature key. 

[0039] This procedure of approving another program- 
mer's public signature key is not applicable to O/S ver- 
ification. It is important to always control the O/S be- 
cause it ensures that the security features imposed by 
the O/S cannot be circumvented. 
[0040] One security feature implemented by the O/S 
that should not be circumvented is creating firewalls 
around data in the memory registers 1 11 to preserve the 
integrity and privacy of the application programs and the 
object files. Both an application program's memory and 
an object files' memory are automatically shielded from 
all other applications that may be running on the com- 
puter platform 1 01 . No special programming by the pro- 
grammers is needed to enjoy this protection. To breach 
a firewall, the O/S will seek permission from two places: 
1 ) the application program requesting the breach and 2) 
the data in memory that is to be accessed. 
[0041] Fig. 8 depicts the process of obtaining the ap- 
propriate permission before allowing access to applica- 
tion programs or object files in memory. For the first step 
801 , the O/S determines if the data in memory to be ac- 
cessed belongs to a secure object file or application pro- 
gram. If the data in memory is not secure, then the O/S 
informs the requesting application program that it is not 
secure. The O/S wilt permit the requesting application 
program to gain access to the insecure data if the re- 
questing application has been written to allow access to 
insecure data as determined in step 803. 
[0042] If the data in memory pertains to secure data, 
then the O/S provides the credentials of the secure tar- 
get data to the requesting application program in step 
805 in order for the requesting application program to 
determine if the credentials are approved in step 807. 
[0043] The O/S will not automatically provide access 
to the secure data if the requesting application program 
approves of the credentials. With secure data, the O/S 
then determines whether the data pertains to an appli- 
cation program or an object file in step 809. 
[0044] If the memory belongs to an object file, then 
the O/S will usually run an object handler associated 
with the object file. The term "object handler" used here- 



in refers to a program that is associated with object files 
that determine if access to that object file is permitted. 
For example, an object handler associated with a par- 
ticular object file might permit access through the fire 
5 wall for an application program which derives from the 
publisher of the object file. The object handler can use 
a number of parameters (publisher, expiration date, plat- 
form identifications, etc.) as criteria for access. If the ob- 
ject handler determines that permission to access the 
desired memory is permitted, the O/S will allow access. 
[0045] Object handlers are usually created by the au- 
thor of the data packet and are included along with the 
data packet that will be digitally signed. However default 
object handlers can created by the O/S for secure object 
files that have no object handler in another embodiment 
of the present invention. 

[0046] If the target data in memory belongs to an ap- 
plication program, then the O/S must then determine if 
the target application approves of the requesting appli- 
cation program. The next step 811 is to determine if the 
requesting application is secure. Depending on the re- 
questing application's secure status, either the creden- 
tials of the requesting application is communicated to 
the target application program in step 81 3 or the fact 
that it is insecure is communicated to the target appli- 
cation program. In either case, the target program ap- 
plication must determine if access to its memory is 
granted as depicted in steps 815 and 817 respectively. 
[0047] Obtaining permission to breach a firewall must 
be obtained every new instance in which an application 
program requests access to data in memory. Once an 
application program obtains permission to access the 
memory, the application program does not have to ob- 
tain permission again until it terminates its access. Once 
access is terminated, a successive request for access 
to data in memory will treated as a new instance and the 
requisite permission must be obtained. 
[0048] By rigorously protecting the integrity of appli- 
cation programs and object files in memory, the system 
minimizes the damage caused by computer malfunc- 
tions. Any malfunctioning application program or com- 
puter viruses can be blocked from affecting other pro- 
gram applications and object files. The firewall essen- 
tially isolates potential adverse effects to application 
programs and object files. 

[0049] Firewalls also allow the system to extend the 
control over data transmissions exerted through data 
encryption and signature authentication to cover the da- 
ta while in the computer platform's memory. Once in the 
computer platform's memory, unauthorized access is 
blocked by the combination of the firewalls and the ap- 
proval process through object handlers and application 
program approvals. Thus, unauthorized access to the 
data is prevented from the time of the creation of the 
digital signature through to the transmission of the data 
to the computer platform and use on the platform. 
[0050] Unauthorized access to the data can also be 
prevented when the data is exported out of the computer 
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platform by applying the encryption/decryption process 
to all data being transmitted out of the computer plat- 
form. Every time that any data marked as secure is 
transferred out of the computer platform, the computer 
platform encrypts the data with the computer platform's 5 
encryption key. By encrypting the data, this prevents an- 
yone who does not have that computer platform's de- 
cryption key from improperly accessing the data that has 
been transferred out of the platform. 
[0051 ] A variety of data may be designated as sensi- 10 
tive by the OS, meaning that it is undesirable for other 
entities to leam the contents of this data. For example, 
the OS may designate as sensitive data that it receives 
in encrypted form. The OS may automatically deem por- 
tions of the memory used by a secure application to be '5 
sensitive. Or it may act on a request, generated by an 
application or the OS itself, that data be designated as 
being sensitive. 

[0052] Normally, sensitive date is kept within the com- 
puter platform. However, due to memory limitations or 20 
to enable backups, it may be necessary to export sen- 
sitive data from the computer platform. In the preferred 
embodiment of the invention, information that is desig- 
nated as sensitive by the OS is encrypted when it is 
transmitted, in its entirety or in part, out of the computer 25 
platform, and decrypted when it is reimported into the 
computer platform. In the preferred embodiment of the 
invention, the OS performs these encryption and de- 
cryption steps automatically. Other modes of operation 
are possible and may be more suitable for specific con- 30 
texts. For example, the OS may query the computer 
platform's user or applications residing on the computer 
platform before performing the encryption or decryption 
operations. By controlling access to data that has been 
transferred out of the platform, the invented system ef- 35 
fects control over access to the data in all instances of 
potential access after the digital signature is created. 
Besides fraudulently securing permission by accessing 
the secret and private keys, a person must pass the im- 
plemented security measures to gain access to secure *o 
data. These security features do not impose restrictive 
rules upon the application programmer because inse- 
cure application programs and object files can still op- 
erate on the invented system. 

[0053] The present invention is not to be considered «5 
limited in scope by the preferred embodiments de- 
scribed in the specification. The software for the system 
by which the method of the invention is executed can 
be stored on any suitable computer readable medium 
such as fioppy disc, computer hard drive, CD-ROM, so 
Flash ROM, non-volatile ROM and RAM. The medium 
can be magnetically or optically readable. Additional ad- 
vantages and modifications, which readily occur to 
those skilled in the art from consideration and specifica- 
tion and practice of this invention are intended to be 55 
within the scope of the following claims. 



Claims 

1 . A data control system comprising: 

a computer platform operable to authenticate 
an operating system to be loaded on the plat- 
form and preventing the operating system from 
being loaded onto the platform when the oper- 
ating system is not authenticated; 
a memory in which application programs and 
object files can be stored, the operating system 
being operable to create a firewall around data 
in memory pertaining to application programs 
and object files to control access to the appli- 
cation programs and object files; 
an input interface connected with the platform 
to allow input data to be received by the plat- 
form, the operating system beingcapable of de- 
crypting the input data and of authenticating the 
input data, and the firewalls around the data in 
memory being capable of allowing the applica- 
tion programs to access the data in memory 
when approval of access is obtained from the 
application program and from the data in mem- 
ory; and 

an output interface connected to the platform 
to allow the platform to transmit output data out 
of the platform, which output data is encrypted 
when transmitted. 

2. A data control system as claimed in claim 1 , wherein 
the platform authenticates the operating system by 
verifying a digital signature associated with the op- 
erating system. 

3. A data control system as claimed in claim 1 or 2, 
wherein the operating system decrypts the input da- 
ta with a private decryption key unique to the plat- 
form. 

4. A data control system asclaimed in claim 3, further 
comprising a sending station capable of encrypting 
data with a public encryption key; said public en- 
cryption key being directly related to said private de- 
cryption key of said computer platform. 

5. A data control system as claimed in any of claims 1 
to 4, wherein the operating system authenticates 
the input data by verifying a digital signature asso- 
ciated with the input data with a public signature key 
and input data that is not authenticated by said op- 
erating system is classified as insecure data. 

6. A data control system as claimed in any of claims 1 
to 5, wherein the output interface encrypts the out- 
put data when the output data includes at least a 
portion of data that has been authenticated by the 
operating system. 



6 



11 



EP 1 168 141 A2 



12 



7. A data control system as claimed in claim 5, further 
comprising a sending station capable of creating a 
digital signature with a secret signature key; the se- 
cret signature key being distinctively associated 
with the sending station. 5 

8. A data control system as claimed in any of claims 1 
to 4 : wherein the operating system is capable of au- 
thenticating the input data by using a hash function. 

10 

9. A data control system as claimed in any of claims 1 
to 8. wherein the data in memory gives approval for 
access through an object handler associated with 
each of the object files when the data in memory 
pertains to the object files. is 

10. A data control system as claimed in any of claims 1 
to 9, wherein the output data is encrypted with a 
public encryption key unique to the platform. 

20 

11. A data control system as claimed in claim 10, 
wherein the output data is decrypted with a private 
decryption key associated with the public encryp- 
tion key. 

25 

12. A data control system as claimed in any of claims 1 
to 11 in which the computer platform includes hard- 
ware for authenticating the operating system and 
preventing the operating system being loaded when 

it is not authenticated. 30 

13. A data control system comprising: 

a sending station, including: (a) a plurality of ap- 
plication programs, (b) a plurality of object files, 35 
(c) a plurality of handler programs, each asso- 
ciated with a separate one of said object files; 
and (d) a plurality of secret key encoded signa- 
tures, each distinctive to a subset of said appli- 
cation programs and said object files; *o 
a plurality of receiving platforms, each having 
firmware and an operating system, the 
f irmware being operable to authenticate the op- 
erating system, 

each of the receiving platforms being adapted « 
to receive the application programs, object 
files, handlers and signatures, and each of the 
receiving platforms having: (a) a public signa- 
ture identification key to authenticate the signa- 
tures and (b) firewalls associated with the ap- so 
plication programs and object files to control 
access to each of the application programs and 
object files, one of the handler programs asso- 
ciated with each of the object files being oper- 
able to permit access to the associated object 55 
files by an appropriate one or more of the ap- 
plication programs; and each of the handler 
programs being programmable to permit multi- 



parameter control over access to the associat- 
ed object files. 

14. The data control system of claim 13 wherein: the 
object files and the application programs at the 
sending station are encrypted with a public key 
unique to the receiving platform being addressed 
and wherein the encrypted object files and applica- 
tion programs are decrypted with a private key, at 
the receiving platform. 

15. The data control system of claim 13 or 16, wherein 
the signature identification is provided through a 
signature creation algorithm and a secret key at the 
sending station, and through a signature verification 
algorithm and a public key at each receiving plat- 
form. 

16. The system of any of claims 13 to 15 wherein: 

the sending station has a plurality of secret key 
encoded signatures, each signature being dis- 
tinctive to a separate set of application pro- 
grams apd data texts, 

each receiving platform having a plurality of 
public signature identification keys to corre- 
spond to the plurality of secret keys at the send- 
ing station. 

17. A method for providing a data control system, com- 
prising the steps of: 

authenticating an operating system to be load- 
ed on a computer platform; the authenticating 
step to be performed every time an operating 
system is loaded on the computer platform; 
verifying credentials of data transmitted to the 
computer platform before loading the data into 
memory of the computerplatform; 
creating firewalls around data loaded into mem- 
ory. of the computer platform; 
decrypting data transmitted to the computer 
platform with a private decryption key unique to 
the computer platform; and 
encrypting data transferred out of the computer 
platform with a public encryption key unique to 
the computer platform and associated with the 
public decryption key. 

18. A method as claimed in claim 17, wherein the au- 
thenticating step is performed by verifying a digital 
signature associated with the operating system. 

1 9. A method as claimed in claim 1 7 or 1 8, furthercom- 
prising the step of obtaining permission before al- 
lowing an application program to access data load- 
ed into memory. 
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20. A method as claimed in claim 19 wherein the ob- 
taining step is performed through object handlers. 

21. A computer readable medium having computer-ex- 
ecutable instructions for performing the method of 5 
any of claims 16 to 20. 
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